dev server console: skip only array indices when listing the named keys of an array - #47905

Origin

• Found during the review of console: print the named properties of an empty array #45564: a review comment there asked for the quoted label, and the dropped keys came from a read of the same loop. No user reported it.
• The echo is on in the three bun init React templates (src/runtime/cli/init/react-app/src/index.ts:37). The docs name agents that watch the terminal as an audience (docs/bundler/html-static.mdx:365).
• Both statements of the old loop date from the first commit of the file (--console & console: true  #19427).

Scope

• An array with no elements still prints [], and an accessor at a named key is still read. Open PR console: print the named properties of an empty array #45564 changes both. It edits the same loop, so the second of the two PRs to land needs a small rebase: keep its try/catch body inside this loop, with this index test and the formatPropertyKey label.
• Open PR dev server: console forwarding does not throw into or hang the page #47937 (at abe1d49) also edits this loop: it puts a try/catch around the output.push. git merge-file gives one conflict there, in either order. The test file merges with no conflict. The second of the two PRs to land needs a small rebase. Keep this loop with its index test, and put that try/catch around its output.push. The catch prints the formatPropertyKey(key) label too, not the raw key.
• With both PRs and that loop on main e57d89b, bun bd test test/bake/dev/esm.test.ts passes 23 of 23 tests. In that build, a getter that throws at a restored key prints [ 5, 6, ok: 2, '1.5': [threw while printing] ], and console.log returns. The tests catch two wrong merges. The loop of dev server: console forwarding does not throw into or hang the page #47937 alone fails this PR's test. This loop with no try/catch fails a test of dev server: console forwarding does not throw into or hang the page #47937. No test holds the label in the catch: a raw key there passes all 23 tests.
• console: print the named properties of an empty array #45564, dev server: console forwarding does not throw into or hang the page #47937 and this PR each conflict with the other two in one hunk of inspect.ts, this loop, and in no other file.
• console.error uses the same call (hmr-runtime-client.ts:332), so the test logs through console.log only.

Own keys that this formatter still does not print. This PR changes none of them, and no tracking issue exists for them:

• formatError (inspect.ts:502) returns only stack. console.error(Object.assign(new Error("boom"), { code: "E_X" })) reaches the terminal without code. Node and Bun's own console print it.
• The depth limit (inspect.ts:205) cuts one level earlier than Node: console.log({ rows: [arr] }) prints { rows: [ [Array] ] }. A restored key shows only when the array is the logged value or one level below it.
• Named keys of functions, Date, RegExp, Map, Set, WeakMap, WeakSet, Promise, typed arrays, DataView and ArrayBuffer. Bun's own console prints none of these either.
• Symbol keys and non-enumerable keys.

Text that changes for arrays that print today

• Non-identifier named keys gain quotes: a b, -1, 1_0, 4294967295, $x, x-y, é, it's. An own __proto__ key prints as ['__proto__']. This is the text formatPlainObject prints for the same key.
• 56 of 56 corpus values with no named key on an array are byte-identical to main. 9 of 9 arrays whose named keys are identifiers (regex match results, rows.columns, tagged template strings) are byte-identical.
• The sweep is synthetic. It says what the two formatters print, not how often a page hits this. It has 16,125 keys (each string of up to 4 characters from 0 1 2 9 . - + e x space a, plus 20 chosen keys) on arrays of length 1, 2, 11, 101 and 150. Of the 80,625 pairs: 7,310 are identical to main, 3,434 are restored, 69,881 are relabelled with quotes, 0 other. The index test agrees with the engine's own-key order for every pair, on JSC and V8.
• For 47,607 pairs on arrays of length 1, 2 and 5, the whole text equals util.inspect of Node v26.3.0.

Costs (formatter imported directly. JSC is bun 1.4.3-canary.1, V8 is node v26.3.0)

These numbers compare this diff with the file before it. They need a new run only when inspect.ts changes.

• bake.client.js: 53,080 B raw (main 53,066), 17,784 B zstd-19 (main 17,762).
• Runtime boot: +1 RegExp object per page load (forwarding on or off), +0 operations per console call with forwarding off. The unminified bundle differs by one top-level statement and the loop.
• Heap per inspect() of a 1,000-element array: V8 12,316 B in 20.36 objects (main 12,460 B in 23.36), JSC 1,004.14 cells (main 1,007.13). Per-key objects: 0. A logged [] costs one object less, because formatArray no longer has a closure.
• Key pass on 1,000 elements: 1,000 regex tests, 0 Number() calls, 0 callback calls, 1 length read (main 0 / 3,000 / 1,000 / 1,000). Regex match result: +3 formatPropertyKey calls.
• Getter at a restored key: 1 call per log (main 0, identifier-named key on main 1). A getter that throws there now throws out of inspect(), as one at an identifier-named key does on main. With dev server: console forwarding does not throw into or hang the page #47937 it prints [threw while printing].
• A non-empty array now runs a RegExp test that matches, so it overwrites the legacy statics (RegExp.lastMatch, RegExp.$1). On main, an object with a key does the same. A logged [] does not.

Steady-state instructions per inspect() call against main, by the top tier the engine may use, at 10 and 1,000 elements (user space, perf_event_open, the slope between two fresh processes, medians of 3):

• In node v26.3.0, formatArray reaches TurboFan at about call 5,400 for 10 elements and call 190 for 1,000 elements.
• A logged [] needs 1% to 4% fewer instructions. A 4-key object is within 1% of main.
• Wall-clock per inspect() call against main at 10 / 1,000 / 100,000 elements, interleaved medians of 9 rounds: JSC -0.9% / +2.1% / +3.9% (A/A gap up to 2.0%), V8 +5.9% / +9.9% / -2.5% (A/A gap up to 3.8%). First call in a fresh process, 10 elements, median of 13: V8 0.319 ms (main 0.261 ms), JSC 0.517 ms (main 0.539 ms).
• A character scan in place of the regular expression needs fewer instructions than main in V8 Maglev and TurboFan (10 elements -20% and -10%, 1,000 elements -42% and -22%). In V8 Ignition and Sparkplug it needs 67% and 58% more at 1,000 elements. The regular expression has the smaller worst case and is one line.